Technical Reviews

Source: Handbook of Walkthroughs, Inspections, and Technical Reviews
by Daniel P. Freedman & Gerald M. Weinberg, 1977

According to the book, the reasons for technical reviews are to

1) Point out needed improvements in a product of a single person or team;

2) Confirm those parts of a product in which improvement is either not desired or not needed;

3) Achieve technical work of more uniform, or at least more predictable, quality than can be achieved without reviews, in order to make technical work more manageable.

There is additional justification related to modern software development methodologies: to

a) Assure that more than one person has seen each part of the projects and has a basic understanding of it (this is also one reason for pair programming);

b) Identify reusable components within a project or across projects (code reuse is one goal of object-oriented programming);

c) Provide data on common mistakes that can then be used in testing (the tests can be added to JUnit or SUnit test suites);

d) Locate areas where code or function is duplicated (the current best practice is to do it once and only once, unless redundancy is specifically called for).

The review can take one of several different forms, such as

Walkthrough Inspection

Round-robin review Informal review

Review materials can include

Functional specifications Designs

Code Documentation

Test plans Tools and packages

Training materials and plans Procedures and standards

Operations and maintenance procedures

Participants in the reviews are often

Review specialists Other team or department members

Experts in the subject matter being reviewed People interested in the product

Visitors/volunteers wanting to contribute Invited people from elsewhere in the organization

Management Producer of the reviewed material

At least three roles need to be filled during the review: the roles of

Recorder Review leader

Reviewer

Others might include

Program writer Reader

The producer and reviewers can use creative tactics. Tactics include

Playing Devil’s advocate Instituting stand-up reviews

Bebugging Money bowl

The alarm Playing the issues list bloodhound

The review can result in various reports such as

Summary report Issues list

Related issue report System history